Track Finding Cleanup, main branch (2025.01.07.) #808
Conversation
krasznaa
added
cuda
Introduced the globalIndex_t typedef for the unsigned int type. Switched all track finding functions to using it instead of std::size_t. Removed all unnecessary templating from functions that were never updated after the track finding configuration became a simple standalone struct. Removed some unnecessary const declarations from the payload structs, and added some extra const declarations in some of the function bodies.
krasznaa
force-pushed
the
TrackFindingCleanup-main-20250107
branch
from
c644de5 to
febca64
Compare
Running too many CUDA tests in parallel requires a *lot* of memory. This will hopefully make the tests a bit more reliable.
|
@paulgessinger, the GitLab CI tests failure on my last commit was a weird one. After looking at it for a bit this morning, my educated guess is that the test ran out of (host) memory. 🤔 CTest was ordered to use all the cores of the test machine. Which sounds perfectly reasonable. But unfortunately this results in the CUDA driver starting to JIT compile the CUDA kernels in parallel in many processes. On my desktop with 32 GBs of memory and 20 GBs of swap I almost ran out of memory with this. 😦 For now I just reduced the number of parallel tests in the GitLab CI. 🤔 Hopefully this will not slow things down too much. This way we'll anyway make use of the CUDA driver's caching in a better way. (Once one process JIT compiles the kernel, the next process doesn't need to do it again.) Let's see if the test now succeeds. 🤞 (I ran the flagged test through |
|
@krasznaa Yeah the host memory is not a whole lot on the machine, so I can easily see it going out of memory. |
device/common/include/traccc/finding/device/propagate_to_next_surface.hpp
Show resolved
Hide resolved
|
As one of the final steps before finalizing #773, this PR is meant to make all the necessary changes in the common device track finding code that SYCL needs.
traccc::device::globalIndex_tto refer to the type of the "global index" that is given to most device functions. (Practically all the ones that don't receive a templated "thread ID" object.)traccc::device::globalIndex_t.consttypes here and there.conststatements from the "payload types". Payload objects are already given to the functions through const references. Making some (simple scalar) members of these payload objects asconsthas no upside in my mind.conststatements on some device vectors here and there.constin the.ippfiles. I just personally like this formalism, where in the.hppfiles we don't bother with adding aconst(since adding it or not makes no difference for the user of the function), but add it in the implementation for a little extra security. (Making sure that we wouldn't change these values by mistake.)